feat(design): show field errors from the API - #576

Please address the comments from this code review:

## Individual Comments

### Comment 1
<location path="packages/ecc-utils-design/src/utils/problem-details.ts" line_range="157" />
<code_context>
+        method: 'POST',
+        headers: { 'Content-Type': 'application/json' },
+        body: JSON.stringify(body),
+      });
+    } catch {
+      this.generalError = 'The registry could not be reached.';
</code_context>
<issue_to_address>
**API response forges inherited extensions**

When an API response contains an object-valued `__proto__` extension and a caller later reads properties from `problem.extensions`, `extensions[key] = body[key]` invokes the `__proto__` setter when a response contains an object-valued `__proto__` extension, changing the prototype of the returned `extensions` object instead of storing that member as data. Downstream callers then see attacker-controlled inherited properties when reading extension values.

Build `extensions` with a null prototype or define extension keys as own data properties so `__proto__` cannot alter its prototype.
</issue_to_address>

### Comment 2
<location path="apps/documentation/pages/docs/design/field-errors.mdx" line_range="126-127" />
<code_context>
+      FIELDS,
+      `The service could not be registered (${response.status}).`,
+    );
+    this.fieldErrors = mapped.fieldErrors;
+    this.generalError = mapped.generalError ?? '';
+  }
+
</code_context>
<issue_to_address>
**Older responses overwrite newer errors**

When two submissions overlap and the older request resolves last, `submit()` applies the older response’s mapped errors after the newer submission completes, so the form shows outdated validation state or errors after a newer successful response.

Ignore a submission’s result when a newer submission has already started.
</issue_to_address>

### Comment 3
<location path="packages/ecc-utils-design/src/utils/problem-details.ts" line_range="118" />
<code_context>
+      return undefined;
+    }
+  }
+  if (plain !== "" && !plain.startsWith("/")) return undefined;
+  return plain;
+}
</code_context>
<issue_to_address>
**Malformed locations match the wrong field**

When an API returns a pointer with an invalid tilde escape that matches a configured field location, `normalizePointer()` checks only that the pointer starts with `/`, so it accepts invalid RFC 6901 escapes; `mapFieldErrors()` can then attach the error to the wrong field instead of treating it as unmatched.

Reject pointers containing any `~` not followed by `0` or `1`.
</issue_to_address>

### Comment 4
<location path="packages/ecc-utils-design/src/utils/problem-details.ts" line_range="152" />
<code_context>
+ */
+export function parseProblemDetails(body: unknown): ProblemDetails | undefined {
+  if (!isObject(body)) return undefined;
+  if (!["type", "title", "status", "detail", "errors"].some((m) => m in body))
+    return undefined;
+  const extensions: Record<string, unknown> = {};
</code_context>
<issue_to_address>
**Valid problems with only instance are discarded**

When a problem-details response contains `instance` but none of the other members checked by the recognition guard, `parseProblemDetails()` omits `instance` from its recognition check and returns `undefined`, so `readProblemDetails()` discards the valid problem and callers lose its occurrence URI and other parsed details.

Include `instance` among the members that qualify a body as problem details.
</issue_to_address>

### Comment 5
<location path="packages/ecc-utils-design/src/components/input/input.ts" line_range="53" />
<code_context>
     const checkboxClasses = cn(
-      "peer h-4 w-4 shrink-0 rounded-[4px] border border-primary shadow focus-visible:outline-none focus-visible:ring-1 focus-visible:ring-ring disabled:cursor-not-allowed disabled:opacity-50",
+      "peer h-4 w-4 shrink-0 rounded-[4px] border shadow focus-visible:outline-none focus-visible:ring-1 disabled:cursor-not-allowed disabled:opacity-50",
+      isInvalid
+        ? "border-destructive focus-visible:ring-destructive"
+        : "border-primary focus-visible:ring-ring",
</code_context>
<issue_to_address>
**Input focus rings disappear**

When a user keyboard-focuses an input or textarea, keyboard focus on these controls has no visible ring: the new classes set only the ring color, while `focus-visible:outline-none` removes the browser outline and the old `focus-visible:ring-1` width utility was removed. Users lose the prior focus indicator on both controls.

Keep `focus-visible:ring-1` in the base classes for both controls.

Also at `packages/ecc-utils-design/src/components/textarea/textarea.ts:36`.
</issue_to_address>

### Comment 6
<location path="packages/ecc-utils-design/src/utils/problem-details.ts" line_range="257" />
<code_context>
+      .split("/")
+      .map((key) => key.replace(/~1/g, "/").replace(/~0/g, "~"))
+      .join("/");
+  return location ? `${location}: ${error.detail}` : error.detail;
+}
+
</code_context>
<issue_to_address>
**Empty-key locations are omitted**

When an unmatched error points to an object member with an empty-string key, `describeUnmatched()` treats the valid pointer `/` as an absent location, so the general error shows only the detail and omits which field it concerns.

Distinguish an absent location from a valid location that decodes to the empty string.
</issue_to_address>

### Comment 7
<location path="packages/ecc-utils-design/src/form-controls.test.ts" line_range="142" />
<code_context>
+        expect(button().getAttribute("aria-invalid")).to.equal("true");
+        const describedBy = button().getAttribute("aria-describedby")!;
+        expect(
+          trigger.shadowRoot!.getElementById(describedBy)!.textContent?.trim()
+        ).to.equal("Must be one of: a, b.");
+        expect(button().className).to.contain("border-destructive");
</code_context>
<issue_to_address>
**Duplicate error copy stays exposed**

When a select or multi-select displays an error, `shows the error and marks the trigger invalid` checks only the described-by copy's text at `form-controls.test.ts:142`; removing `hidden` from that copy still passes, leaving an extra exposed message that can be announced alongside the live-region error.

Assert that the described-by copy is hidden as well as containing the error text.
</issue_to_address>

### Comment 8
<location path="packages/ecc-utils-design/src/form-controls.test.ts" line_range="81-83" />
<code_context>
+        el.error = "";
+        await el.updateComplete;
+        const control = el.shadowRoot!.querySelector(selector)!;
+        expect(control.hasAttribute("aria-invalid")).to.equal(false);
+        expect(errorElement(el).textContent?.trim()).to.equal("");
+        expect(control.className).to.not.contain("border-destructive");
+      });
+    });
</code_context>
<issue_to_address>
**Stale error description passes**

When an error is cleared after being set, `clears the error` checks the invalid state, message text and border at `form-controls.test.ts:81-83`, and the select test checks only invalid state and border at `:149-150`; both pass if `aria-describedby="error"` remains after clearing, leaving assistive technology pointed at an empty message.

Assert that `aria-describedby` is absent after clearing the error on each control and select trigger.

Also at `packages/ecc-utils-design/src/form-controls.test.ts:149-150`.
</issue_to_address>

### Comment 9
<location path="packages/ecc-utils-design/src/utils/problem-details.test.ts" line_range="153" />
<code_context>
+    expect(problem?.errors).to.have.length(2);
+    expect(
+      await readProblemDetails(response(body, "application/json"))
+    ).to.not.equal(undefined);
+  });
+
</code_context>
<issue_to_address>
**JSON parsing accepts an empty result**

When the `application/json` branch returns a non-`undefined` result without parsing the body, when `readProblemDetails()` returns a non-`undefined` placeholder for an `application/json` body instead of parsing its problem details, `reads problem+json and JSON bodies` passes at `problem-details.test.ts:153`; it never checks the JSON response's parsed errors or other content.

Assert that the parsed `application/json` response contains the expected errors or another known member from `RFC_EXAMPLE`.
</issue_to_address>